An example of relational access system for network type data bases, enabled to access network type data bases by the SQL, which is a data manipulation language for relational data bases, so that the user can retrieve data on a network type data base as if they were data on a relational data base, is disclosed in "ACOS-4/XVP ADBS GENERAL DESCRIPTION, DRB81E-2, NEC CORPORATION, 1992, pp. 4-1 to 4-37" and "ACOS-4/XVP ADBS DESIGN GUIDE, DRB85E-2, NEC CORPORATION, 1992, pp. 6-1 to 6-13".
FIG. 8 is a diagram illustrating the configuration of the prior art relational access system for network type data bases disclosed in these publications.
This conventional relational access system for network type data bases consists of schema deriving means 1', into which a subschema 5 is entered, for supplying a relational schema 6'; SQL statement translating means 2', into which the relational schema 6' and an SQL statement 7 are entered, for supplying a data manipulation language (DML) object 8'; and DML object executing means 3, into which the DML object 8' and an executional instruction 9 are entered, for accessing a network type data base 10.
The subschema 5, consisting of the logical structure of the parts required by individual processing programs, extracted from a schema (not shown) in which information on the logical structure of the whole network type data base 10 is stored, includes among other things record definitions indicating the structures of records stored in the network type data base 10, set definitions representing relationships among the records, and the definitions of key items, which are the items serving as keys to direct accessing of the records.
FIGS. 9 and 10 illustrate different simple examples of the subschema 5.
The subschema 5 in FIG. 9 includes a department record 511, a section record 512 and an employee record 513, and the record definitions of the department record 511 and the section record 512 are linked by a set 514, while those of the section record 512 and the employee record 513 are linked by a set 515. The department record 511 has the items of "department name", "name of department manager" and "number of employees", and the department name is defined to be the unique retrieval key for use in directly accessing this record. The section record 512 has the items of "section name", "name of section chief" and "number of employees", and the employee record 513 has the items of "name", "address" and "native place". Neither the section record 512 nor the employee record 513 has a unique retrieval key.
The subschema 5 in FIG. 10 is an example of subschema having a tree structure and including the definitions of a department record 501, a section record 502, an employee record 503 and a duty record 504. The record definitions of the department record 501 and the section record 502 are linked by a set 505, those of the section record 502 and the employee record 503 are linked by a set 506, and those of the section record 502 and the duty record 504 are linked by a set 507. The department record 501 has the items of "department name" and "name of department manager", and the department name is defined to be the unique retrieval key for use in directly accessing this record. The section record 502 has the items of "section name" and "name of section chief". The employee record 503 has the items of "name of employee" and so forth, and to the item of "name of employee" is attached an index 508. The duty record 504 has the items of "name of duty" and so forth.
The schema deriving means 1' in FIG. 8 includes table definition generating means 12, into which the subschema 5 of the contents such as shown in FIGS. 9 and 10 are entered, for generating the relational schema 6'.
The relational schema 6' is derived by converting the subschema 5 into a form permitting relational handling, and is so called to distinguish it from the schema and the subschema in the network type data base.
The schema deriving means 1' generates the relational schema 6' from the subschema 5 in accordance with the following conversion rules.
(1) One relational schema is generated from one subschema in a network type data base.
(2) One table definition is generated for one record definition in the subschema.
(3) The columns constituting each table in the relational schema consist of basic columns and additional columns. The basic columns include all the items existing in the original record. The additional columns include items in all the records which constitute the ancestor records of the original record, satisfying the following requirements.
i) The item constitutes some key in a record definition of the schema.
ii) That key is selected by the subschema.
iii) There is only one item to constitute that key.
(4) Correspondence information indicating the relationships of correspondence between the tables in the relational schema and the records, sets, retrieval keys and indices among other things in the subschema are generated at the same time.
One of the reasons why key items among the items of ancestor records are used as additional columns is that, if all the items including non-key items were also incorporated into the additional columns, the number of columns of table definition would become enormous, inviting massive consumption of resources including the main storage and thereby giving rise to performance problems. Another reason is that more than one column having the same name might emerge in one table, which would be inconsistent with the specifications of SQL.
If the above-stated conversion rules are followed, in the case of the subschema 5 in FIG. 9 for instance, the schema driving means 1' generates the relational schema 6' shown in FIG. 9, which includes a department record table 611 in which only basic columns ("department name", "name of department manager" and "number of employees") are defined, a section record table 612 in which basic columns ("section name", "name of section chief" and "number of employees") and an additional column "department name" are defined, an employee record table 613 in which basic columns ("name", "address" and "native place") and an additional column "department name" are defined, and correspondence information 614. The correspondence information 614 indicates that the department record table 611 corresponds to the department record 511, and its retrieval key is the "department name"; that the section record table 612 corresponds to the section record 512, and its additional column "department name" corresponds to the item "department name" in the department record 511 traced through the set 514; and that the employee record table 613 corresponds to the employee record 513, and its additional column "department name" corresponds to the item "department name" in the department record 511 traced through the set 515, section record 512 and set 514.
In the case of the subschema 5 in FIG. 10, the schema deriving means 1' generates the relational schema 6' shown in FIG. 10, which includes a department record table 601 in which only basic columns ("department name" and "name of department manager") are defined, a section record table 602 in which basic columns ("section name" and "name of section chief") and an additional column "department name" are defined, an employee record table 603' in which basic columns ("employee name", . . . ) and an additional column "department name" are defined, a duty record table 604' in which basic columns ("name of duty", . . . ) and an additional column "department name" are defined, and correspondence information 605'. The correspondence information 605' indicates that the department record table 601 corresponds to the department record 501, and its retrieval key is the "department name"; that the section record table 602 corresponds to the section record 502, and its additional column "department name" corresponds to the item "department name" in the department record 501 traced through the set 505; that the employee record table 603' corresponds to the employee record 503, and its additional column "department name" corresponds to the item "department name" in the department record 501 traced through the set 506, section record 502 and set 505; and the duty record table 604' corresponds to the duty record 504, and its additional column "department name" corresponds to the item "department name" in the department record 501 traced through the set 507, section record 502 and set 505.
The SQL statement translating means 2' includes access routing means 22'. An SQL statement 7, in which a data manipulating instruction is stated in SQL, which is a data manipulation language for relational data bases, is entered into the SQL statement translating means 2', which determines with the access routing means 22' the access route to realize access to the network type data base 10 requested by the SQL statement 7 by referring to the relational schema 6' of such contents as are shown in FIGS. 9 and 10, and generates a DML object 8' designating this determined access route. Here, DML is the data manipulation language for the network type data base 10.
Then the DML object executing means 3 specifies the DML object 8' by an executional instruction 9 which has been entered, and the network type data base 10 is accessed by the access route stated in this specified DML object 8'. Incidentally, the executional instruction 9 may be in COBOL or a similar language.
The system according to the prior art uses such a configuration to make a network type data accessible by SQL, a language for relational data bases, and especially, the table definitions of the relational schema are enabled to reflect the parent-descendant relationship based on the concept of "set" in network data bases, and the access designated in SQL is enabled to be achieved in a set-to-set tracing process, by setting in additional columns of table definitions of the relational schema 6' key items in the ancestor record obtained by tracing, in the direction toward the owner, sets linked to record definitions corresponding to those table definitions.
In this conventional system, it is possible to add items which are retrieval keys to the ancestor record as columns of the table generated from a given record. Therefore, if the parent record has a retrieval key, it is possible to designate in an SQL statement to link a table generated from the parent record with a table generated from a descendant record in a column deriving from the retrieval key of the parent record and, moreover, if that retrieval key is a unique key, the set can be uniquely identified, with the result that the network type data base can be accessed by utilizing the set.
This prior art system, however, cannot designate a table link in an SQL statement and accordingly is unable to access a network type data base by utilizing sets if the parent record does not have a retrieval key.
For instance, in the relational schema 6' shown in FIG. 10, there is a column of "department name" but none of "section name" in the employee record table 603' and the duty record 604', and no SQL statement requesting the following table links, for instance, can be expressed.
SELECT name of duty PA1 FROM employee record table, duty record table PA1 WHERE employee record table, department name=duty record table, department name PA1 AND employee record table, section name=duty record table, section name PA1 AND employee name=`Inoue`
An object of the present invention is to make it possible, where a network type data base is to be accessed by SQL which is a language for relational data bases, for table links to be designated in SQL statements for tables generated from parent-descendant records even if no retrieval key, which is unique in the data base, to the parent record in the network type data base exists, and to make the processing of those table links accessible via sets.